[#634] Await agent DB writes and handle cache failures gracefully#651
[#634] Await agent DB writes and handle cache failures gracefully#651realproject7 merged 3 commits intomainfrom
Conversation
- AgentRegister: await DB write, show warning if cache fails - AgentManage: await all three DB writes (URI update, wallet bind, wallet unbind), show warning on failure - agent-register route: handle 23505 unique violation by re-querying and updating the conflicting row - agents/page.tsx + AgentDashboard: retry cacheAgentById once on failure On-chain success is never blocked by DB failure — failures show a user-friendly warning instead of silent swallowing. Fixes #634 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
project7-interns
left a comment
project7-interns
left a comment
There was a problem hiding this comment.
Verdict: REQUEST CHANGES
Summary
The UI now waits for the cache-write requests, but the warning path is still incomplete because the API routes can report success even when the DB write fails.
Findings
- [high]
agent-updateignores Supabase update errors and still returns{ ok: true }, so the new awaitedfetch("/api/user/agent-update")calls inAgentManage.tsxwill still show success even when the cache write actually failed.- File:
src/app/api/user/agent-update/route.ts:80 - Suggestion: Check the returned
errorfromsupabase.from("users").update(...)and return a non-2xx response when the DB write fails so the UI can surface the warning state the issue requires.
- File:
- [high]
agent-registerhas the same problem on its update paths, soAgentRegister.tsxcan still miss cache-write failures after on-chain success.- File:
src/app/api/user/agent-register/route.ts:64 - Suggestion: Validate the result of the
update(...)calls for both the normal existing-user path and the 23505 retry path, and return a failure status if the DB update did not succeed.
- File:
Decision
Requesting changes because the acceptance criteria require cache-write failures to be visible to the user after on-chain success, and the current API routes can still mask those failures behind 200 OK responses.
Both agent-register and agent-update routes now check the error from Supabase update/insert calls and return 500 on failure, so the client-side warning UI can actually trigger. Addresses T2a review feedback on PR #651. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
project7-interns
left a comment
project7-interns
left a comment
There was a problem hiding this comment.
Verdict: REQUEST CHANGES
Summary
The routes now propagate most DB write failures correctly, but the 23505 recovery path in agent-register can still report success without actually updating any row.
Findings
- [high] On the
23505branch, if the follow-up lookup does not return a row, the handler falls through to{ ok: true }even though the insert failed and no update was applied.- File:
src/app/api/user/agent-register/route.ts:75 - Suggestion: Treat "conflict but no matching row found" as a failure path and return a non-2xx response. Otherwise the client still shows cache success on an unresolved race, which defeats the new warning behavior.
- File:
Decision
Requesting changes because the conflict-recovery path is still not reliable end to end: an unresolved 23505 can be masked as success, so rapid re-registration can still silently skip the cache write.
If the concurrent insert conflict re-query finds no matching row,
return 500 instead of falling through to { ok: true }.
Addresses T2a review feedback on PR #651.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
project7-interns
left a comment
project7-interns
left a comment
There was a problem hiding this comment.
Verdict: APPROVE
Summary
The reliability changes now satisfy the requested scope: the cache-write routes propagate DB failures back to the client, the 23505 recovery path no longer falls through as success, and the client flows await cache writes without blocking on-chain success.
Findings
- None.
Decision
Approving on code review. The earlier error-propagation and conflict-fallthrough issues are addressed; remaining CI checks are still running, but they do not block the review verdict.
2 participants
Summary
cacheAgentByIdretries once on failure before giving up.On-chain success is never blocked by DB failure.
Fixes #634
Tracks realproject7/agent-os#314
Test plan
🤖 Generated with Claude Code